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I  Introduction 


Groundwars  is  s  vsapon  systsas  sffsetivsnsas  aodsl  which 
provides  ths  results  of  e  lend  duel  between  two  forces.  The  aodel 
siaulates  individual  weapon  systeas  end  eaploys  Monte  Carlo 
probability  theory  as  its  priaary  solution  technique.  The 
siaulation  is  stochastic  and  event  sequenced. 

Groundwars  is  an  outgrowth  of  the  TAMXWXRS  aodel  (version  ZI) 
originally  written  by  Mr.  Fred  Bunn  of  the  Aray  Research  Laboratory 
(BRL) ,  Aberdeen  Proving  Ground,  Maryland.'  The  original  aodel  has 
been  aodified  to  include  nuaerous  enhanoeaents  and  new 
aethodologies.  The  ciirrent  version  of  the  aodel  is  Groundwars 
Version  S.o. 

A  total  of  6  different  platfoms  can  be  deployed  between  the  two 
forces.  The  user  deteraines  the  sise  of  the  two  forces  (aaxiaua  of 
100  total  systems),  the  range  at  which  the  battle  will  begin,  the 
attack  angle  distribution  to  be  used,  and  the  terrain  statistics  to 
be  used. 

Zntervisibility  between  ooabatants  is  deterained  by  statistical 
terrain  data.  Groundwars  allows  the  user  to  play  aany  different 
terrains,  provided  the  data  is  available.  Three  terrain 
distributions  are  within  the  aodel;  they  are  Eschenbaeh,  Bunfeld, 
and  Peine  and  are  located  in  Germany.  Bahenbaeh  is  choppy  terrain 
with  liaited  opening  range  and  in-view  lengths.  Peine  is  flat  and 
has  long  opening  range  and  in-view  lengths.  Hunfeld  has  aoderate 
ranges.  Table-top  terrain,  in  which  no  liait  exists  on 
intervisibility,  can  also  be  played.  The  aodel  also  allows  the 
user  to  input  other  terrain  distributions  if  another  is  desired. 
Vehicles  in  overwatch  and  defenders  always  have  line-of-sight  to 
one  another. 

Given  that  intervisibility  exists  between  two  eoabatants, 
acquisition  nay  occur.  A  observer  can  acquire  a  target  either  by 
noraal  search  or  by  detection  of  a  the  target's  firing  signature. 
Moraal  acquisition  is  based  on  the  Center  for  Might  Vision  and 
Blectro-Optics  (CMVEO)  target  detection  routines,  and  is  a  function 
r  of  the  sensor,  the  atmosphere,  the  target,  etc.  An  observer  may 
also  detect  a  target's  firing  signature.  Whenever  an  eneay  systea 
fires,  there  is  a  probability  that  the  observer  will  detect  it.  If 
this  probability  is  net,  the  observer  begins  engagement  of  the 
target  after  a  random  period  of  time  which  is  drawn  from  a 


‘  Bunn,  Fred  L.,  The  Suetained  Coiri&al:  Model;  Tankwere  II.  An  Armored 
Combat  Analveie  Program.  ARBRI<“TR-09999,  U.S.  Army  Balliatic  Research 
Laboratory,  APG,  MD,  December  1985 
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distribution  generated  from  test  data. 


Four  types  of  rounds  can  be  played  in  the  model:  kinetic 
energy (KE),  high  explosive  anti-tank (HEAT) ,  anti-tank  guided 
missiles (ATOM) ,  and  fire  and  forget  missile  missiles (FAF) .  For 
each  weapon  the  model  requires  system  characteristics  (firing 
times,  times  of  flight,  reliability) ,  accuracy  data,  and  lethality 
data. 


Three  types  of  target  engagement  can  be  played  in  the  model . 
The  first  is  single  target  engagement  in  which  a  firer  detects  a 
target,  begins  engagement  of  the  target,  and  discontinues  all  other 
actions.  The  second  type  allows  the  firer  to  detect  a  target  and 
begin  engaging,  and  to  concurrently  search  for  additional  targets . 
Once  the  firer  disengages  the  first  target,  he  will  select  the  next 
target  from  his  list  and  begin  engaging  the  next  target .  The  third 
type  of  engagement  can  only  be  played  with  fire  and  forget 
Biissiles.  In  this  type  of  engagement,  the  firer  atteo^ts  to  queue 
a  number  of  targets,  and  then  fire  a  single  shot  at  each  of  the 
queued  targets  nearly  simultaneously. 

A  number  of  co\intermeasures ,  such  as  on  board  smoke  grenades 
can  be  simulated.  When  the  grenade  system  detects  an  incoming 
round,  it  will  la\inch  grenades  arotind  the  vehicle  and  form  a  cloud 
of  smoke  which  may  cause  incoming  missiles  to  abort.  A  second  type 
of  countermeasure  is  an  active  protection  system.  Similar  to  the 
smoke  grenades,  this  system  senses  an  incoming  rotund  aund  either 
destroys,  jams,  or  degrades  the  incoming  projectile.  The  user 
controls  the  level  of  effectiveness  for  these  self-defense  systems . 
Artillery  delivered  smoke  can  also  be  played  on  the  battlefield 
which  will  degrade  acquisition  capabilities. 

Limited  artillery  play  is  also  io^lemented  in  the  model.  Each 
army  can  deploy  one  on-call  mission  during  a  battle,  and  the 
attacking  force  is  given  the  option  to  have  one  preparatory 
artillery  barrage.  For  each  type  of  mission,  there  is  an 
associated  probability  of  kill  which  is  assessed  against  all  enemy 
vehicles  desired.  On-call  artillery  missions  occur  at  random  times 
in  the  battle. 

Groundwars  allows  the  user  to  choose  from  a  couple  of 
disengagement  tactics.  A  firer  will  always  disengage  its  target 
after  it  is  catastrophically  killed.  The  first  optional  tactic  is 
to  disengage  a  target  after  hitting  it.  A  second  optional  tactic 
is  to  fire  a  certain  number  of  rounds  at  a  target  and  then 
disengage.  For  these  optional  tactics,  the  model  allows  a  firer  to 
return  to  a  serviced  target,  if  he  hasn't  found  another  target 
after  a  period  of  time. 

The  primary  measures  of  effectiveness  for  the  simulation  are 
loss  exchange  ratio,  meam  casualties,  system  exchange  ratios,  and 
average  losses  as  a  function  of  time  in  the  battle.  The  secondary 
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measures  include  surviving  force  ratio,  shots,  hits,  and  kills  for 
each  weapon  target  pairing,  and  average  detections  by  each  sensor. 
The  amount  of  output  is  directly  controlled  by  the  user,  and  can 
range  from  averages  to  a  detailed  break  down  of  many  facets  of  the 
battle. 

Groundwars  can  provide  a  trade  off  analysis  between  major 
weapon  system  characteristics  such  as  fire  control,  lethality,  and 
accuracy.  It  can  provide  analysis  for  a  number  of  combat  related 
issues  (i.e.  terrain,  atmospheric  conditions,  attack  angles) .  The 
effects  of  changes  in  target  acquisition,  target  disengagement 
policy,  and  ammunition  storage  can  be  shown  relatively  quickly  and 
easily. 

The  main  limitations  are  that  there  are  no  effects  from 
suppression,  and  only  direct  fire  line  of  sight  weapon  systems  can 
be  simulated.  The  model  plays  only  ground  to  ground  engagements 
with  no  helicopters.  It  does  not  play  the  effects  of  barriers  nor 
does  include  a  dismounted  infantry  modal. 

The  main  strong  point  of  the  model  is  its  quick  set  up  and  run 
time  which  allows  for  examdination  of  many  situations  and 
conditions.  The  model  provides  a  basis  for  modelling  system 
interactions  and  can  enable  an  analyst  to  obtain  a  good 
understanding  of  these  effects  prior  to  large  scale  combined  arms 
modelling. 
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II  Input  Data  Roquiremants 

The  program  has  been  released  with  certain  limits  on  the 
nvifflber  of  units  in  a  battle  (100)  and  the  number  of  different 
vehicle,  weapon  and  sensor  types  which  can  be  played  (6) .  These 
limits  may  be  modified  as  desired.  If  the  user  modifies  these 
limits,  some  additional  modifications  may  be  needed  within  the 
program. 

Groundwars  requires  a  niimber  of  input  files.  There  is  a  game 
control  file  in  which  the  user  determines  the  scenario,  the 
terrain,  and  the  level  of  output  desired.  This  file  also 
determines  the  attack  angle  distribution,  the  visibility 
conditions,  etc. 

For  each  army  there  is  a  wit  deployment  file  in  which  the 
user  sets  the  number  of  units,  the  starting  locations  of  the  units, 
and  the  function  of  the  units  in  the  battle.  A  miscellaneous 
information  file  which  describes  things  such  as  disengagement 
tactic,  artillery  lethality,  and  decoys  for  each  army.  Each  side 
has  a  file  which  describes  its  vehicles,  one  for  its  weapons,  and 
one  for  its  sensors.  For  each  weapon  system  there  is  an  accuracy 
file,  and  for  each  weapon-target  pair  there  may  be  a  lethality 
file. 


If  artillery  delivered  smoke  or  other  obscurants  are  to  be 
played,  a  file  is  required  to  characterise  the  periods  and  levels 
of  obscuration. 

With  the  inclusion  of  fratricide  and  combat  identification 
(CID)  in  the  current  release  version,  additional  files  are  required 
which  describe  engagement  rules  and  CID  effectiveness. 

All  files  except  for  the  Individual  Unit  Action  (lUA)  lethality 
files  are  free  formatted.  Comment  lines  may  be  added  to  the  TOP  of 
any  input  files  by  starting  the  line  with  an  asterisk  (*)  .  Any 
lines  shown  in  the  documentation  are  there  for  clarity  and  the 
program  expects  them  to  be  there.  They  may  be  changed,  but  cannot 
be  deleted. 

Data  which  are  entered  as  character  strings  can  be  a  oiaximum 
of  seven  letters  long  and  can  include  capital  or  small  letters 
(longer  strings  will  be  truncated  to  seven  letters) .  All  times 
which  are  entered  into  the  data  files  are  in  seconds,  and  all 
linear  measurements  (dimensions,  speed,  etc.)  are  in  meters. 

The  program  looks  for  all  of  its  input  files  in  the  current 
working  directory.  All  input  files  which  are  needed  for  the  battle 
which  the  user  wishes  to  rw  must  be  assonbled  into  the  current 
directory  prior  to  execution  of  the  program.  The  program  looks  to 


4 


use  files  with  specific  names.  These  names  will  be  explained  in  the 
different  input  sections.  A  sanqple  set  of  inputs  and  files  is 
given  later  in  this  document . 
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II. A  Gam*  Control  Filo 


Thin  filn  dnfinns  thn  tcnnnrio  to  bn  plnynd  and  controls  thn 
lavnl  of  output.  Thn  flln  aunt  bn  naand  **gaan*'  in  thn  currnnt 
working  dirnetory  for  thn  prograa  to  rnad  it.  Thn  gnnnral 
ntructxirn  of  thn  filn  is  shown  in  Figurn  1. _ 


•*  coment  Line(a) 

Scanario:  RED  Attack,  BLUE  Attack,  STATIONARY  Engagaroant 

Terrain:  Paine,  Hunfeld,  Eschenbach,  Table*top,  or  Other 

Attack  Angle  Diatribution:  Cardioid,  Frontal, 

CV-CPOA,  Cloae  Combat 

Atmospheric  Visibility  Range,  Optical  Attenuation,  Thermal  Attenuation 
Output  Control  Flags  (7) 

Program  Debug  Flags  (30) 

Range  Increment  for  Input 

Maximum  Battle  Time 

Increments  for  Output:  Time,  Range 

Maximum  Number  of  Replications,  Initial  Random  Seed 
Pinpoint  Restriction 

Statistical  Confidence  Level,  Relative  Width 


Figure  1  Game  Control  File 

Ths  first  thrss  linos  of  ths  fils  sot  ths  typo  of  sngsgsaont, 
ths  torrsin,  snd  ths  sttsck  sngls  distribution.  Inch  of  thsss 
rsquirss  s  chsractsr  string  for  input.  For  lias  i  ths  ussr  inputs 
RED  sttsck,  BLUE  sttsck,  or  STATIONARY  sngsgswsnt.  in  sn  sttsck 
sesnsrio  ths  sttscking  smy  csn  dslivsr  s  prop  srtillsry  bsrrsgs 
snd  possibly  kill  sows  snswiss  prior  to  ths  dirset  firs  bsttls. 
Intsrvisibility  is  dstsrainsd  by  ths  uso  of  ths  tsrrsin 
>  distribution  sslsctsd  on  tbs  nszt  lins.  In  ths  stationary 
sagsgswsat,  no  prop  srtillsry  kills  srs  sssosssd.  Intsrvisibility 
sxists  bstwssn  all  ooabstsnts,  snd  ths  tsrrsin  statistics  srs  not 
ussd. 


Intsrvisibility  bstwssn  oowbstsnts  for  attack  scsnsrios  is 
dstsrwinsd  by  using  statistical  distributions  which  ohsrsctsriss  a 
particular  pises  of  tsrrsin.  Ths  wodsl  contains  ths  terrain 
distributions  for  thrss  arsas  in  osraany:  Eaohsnbach,  Hunfsld,  and 
Fsins.  Ths  ussr  can  also  specify  tabls-top  terrain  which  ensures 
continuous  lins-of •sight  bstwssn  all  ooabatants.  If  ths  ussr 
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vish«8  to  US*  s  tsrrsln  which  is  not  in  ths  sodsl,  this  csn  bs  dons 
by  sotting  ths  tsrrain  to  OTHER*  and  sntsring  ths  appro|«riats 
distributions  dsscribsd  latsr  in  this  ssction. 


Ths  ussr  dsfinss  ths  attack  angls  distribution  to  bs  ussd«  and 
has  choiess  of  CARDioiD*  frontal*  cv-cpoa*  and  close  combat.  Ths 
attack  angls  distribution  is  ussd  to  dstsmins  ths  angls  of  impact 
for  all  rounds  firsd.  Sss  Appendix  A  for  a  graphical 
rsprsssntation  of  ths  distributions. 

Ths  ussr  thsn  spscifiss  ths  atmospheric  conditions  for  ths 
battle.  Ths  mstsorologic  visibility  range  is  given  first,  and  thsn 
ths  corresponding  atmospheric  attenuation  coefficients  for  optical 
transmission  and  for  thermal  transmission,  rsspsctivsly.  Thsss 
inputs  are  ussd  for  ths  corresponding  sensor  types  when  acquisition 
capabilities  are  calculated  during  a  battle. 


Ths  seven  output  control  flags  on  line  4  determine  the  detail 
and  amount  of  output  that  will  be  generated  for  a  battle.  If  all 
flags  are  set  to  0,  the  basic  output  will  be  generated.  The  output 
generated  by  setting  the  flags  to  non-sero  are  shown  in  the  figure. 


fl4a  Incut  fifi.gPxikEti«?n 


4 

5 

6 
7 


1  -  normal  output  plus  a  one  line  summary  of  each  replication 

2  -  normal  output  plus  a  detailed  account  of  all  critical  events] 

in  the  battle 

(DO  NOT  run  more  than  1  replication) 

1  -  output  of  weapon  system  characteristics 

(round  type*  firing  times,  reliability*  etc.) 

2  ->  sample  of  lethality  data  for  each  %raapon-target  pairing 

1  -  output  of  acquisition  estimates  for  each  sensor 

2  -  output  of  acquisition  estimates  for  every  change  in 

atmospherics  caused  by  artillery  smoke 

1  -  trace  entry  and  exit  from  important  routines 

(DO  NOT  run  for  more  than  1  replication) 

1  -  output  all  events  as  they  are  scheduled  and  canceled 

(DO  NOT  run  for  more  than  1  replication) 

1  -  output  of  killer  victim  scoreboards  by  range 

1  -  output  of  the  distribution  of  shots  for  each  weapon  type 


Figure  2  Output  Control  Flags 


Flag  2  sehoss  soms  of  ths  inputs  to  ths  output  fils  so  that  ths 
ussr  oan  ohsck  for  input  srrors.  Analysis  of  acquisition 
oapabilitiss  is  aided  by  printing  acquisition  probability  and  tins 
sstimatss  as  a  function  of  rang*  for  saeh  ssnsor-targst  pairing 
(flag  3) .  Ths  output  gsnsratsd  L;-'  thsss  two  flags  may  bs  produced 
with  or  without  running  a  battle.  To  produce  this  output  without 


rimning  a  battla  sat  tha  nuabar  of  raplicationa  to  o. 

Tba  nazt  lina  contains  30  flags  vbich  control  output  for 
prograa  debugging.  Tha  flags  should  not  ba  sat  >  0  for  aora  than 
a  singla  replication. 

On  lina  6  the  user  enters  the  data-input  range  incraaant. 
This  incraaant  will  ba  used  whan  the  aodal  reads  other  inputs 
including  lethality*  accuracy*  firing  tiaas*  etc. 

The  aaaiaua  battle  tiaa  is  input  on  the  next  lina.  This  tiaa 
will  ba  used  to  and  the  battle  unless  all  eoabatants  on  one  side 
are  dead  or  non- f tine t  ion  ing. 

The  next  lina  controls  the  output  of  certain  aaasuras  of 
affactivanass  which  are  recorded  and  reported  as  a  function  of 
either  tiaa  or  range.  Average  RED  and  BLOB  losses  and  exchange 
ratio  are  output  as  a  function  of  battle  tiaa.  The  first  nuaber  on 
this  line  is  the  tiaa  incraaant  for  this  output.  The  second  entry 
on  the  line  is  the  range  increaent  for  the  output  of  acquisitions* 
shots*  hits*  and  kills  as  a  function  of  range. 

On  line  9  the  user  sets  the  aaxiaua  ntiaber  of  replications  to 
be  played.  This  nuaber  will  be  used  only  if  the  desired  level  of 
statistical  confidence  has  not  been  reached  by  this  point.  The 
second  input  on  this  line  is  the  initial  randoa  nuaber  seed. 

The  ability  of  an  observer  to  detect  a  target's  firing 
signature  (pinpoint)  can  be  restricted  by  the  next  input.  Entering 
a  0  allows  observers  to  detect  firing  signatures  regardless  of  the 
their  ability  to  detect  by  nomal  search.  By  entering  a  i  on  this 
line  the  user  restricts  observers'  capabilities  to  pinpoint.  The 
observer  can  pinpoint  only  if  he  has  P- infinity  greater  than  0.0  at 
the  target  range. 

The  last  line  of  the  file  pertains  to  the  confidence  level  of 
the  output  for  RED  dead*  BLUE  dead*  and  Exchange  Ratio.  These 
inputs  are  used  to  terxinate  the  simulation  if  the  desired  level  of 
confidence  has  been  reached.  The  xodel  records  the  results  from 
each  of  the  replications  and  calculates  the  mean  and  standard 
deviation  for  all  preceding  replications.  Xf  the  results  xeet  the 
«  statistical  criteria  which  the  user  sets  for  all  three  of  the  above 
■easures  of  effectiveness  the  aodel  terminates  execution.  The  user 
specifies  the  level  of  confidence  (80*  90*  95*  98*  or  99}  and  the 
relative  width  (usually  between  .05  and  .15).  Por  example*  if  the 
user  specified  95  percent  confidence  and  a  .05  for  the  relative 
width*  then  he  could  be  95  percent  confident  that  the  true  mean  of 
the  distribution  is  within  5  percent  of  the  displayed  mean. 

If  a  user  defined  terrain  is  being  used  (OTHER  was  specified 
for  the  terrain)*  there  is  an  additional  section  to  the  file.  Por 
intervisibility  the  aodel  first  finds  the  range  at  which  line  of 
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found,  the  model  draws  alternating  in  and  out  of  view  segments  of 
varying  lengths.  The  lengths  of  these  segments  are  drawn  from  two 
additional  distributions.  The  format  for  entering  the  three 
distributions,  first  opening  range,  in-view  segment  lengths,  and 
out  of  view  segment  lengths,  is  shown  below.  Note  the  probability 
distributions  are  cumulative  and  the  values  for  the  longest  ranges 
must  be  1.0. 


Number 

of  Points  in: 

Opening  Range  Dist., 

In  and  Out  of  View  Segment  Length  Dist.'s 

Rangel 

P{0pen)  *** 

First  Opening  Range  Distribution 

Range2 

P (Open) 

RangeN 

i!o 

Rangel 

P  (In-view) 

P (Out-of-view) 

Range2 

P (In-view) 

P (Out-of-view) 

RangeN 

i!o 

1.0 

Figure  3  Input  of  "OTHER"  Terrain 
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II. B  Unit  D«ploym(iiit  Fil* 


In  thn  unit  dnploynnnt  fil«  thn  u««r  dnfinns  th«  fores  siio, 
the  location,  tho  •zposuro  and  tha  type  of  conbatanta  for  aach 
any.  Vitbin  this  fila,  tba  usar  spacifias  tba  naaas  of  tha 
vahiclas,  vaapona,  and  aanaora  which  will  ba  uaad  in  tha 
simulation.  Thasa  namas  ara  ii^ortant,  as  thay  will  ba  uaad 
throughout  tha  othar  data  filaa.  Bach  any  has  a  unit  daploymant 
fila  which  must  ba  nanad  bunit  for  BLUB  and  runit  for  RBD.  Tha 
atructura  of  thasa  filaa  is  shown  balow. 


*•*  conment  Z<lne(8) 

*  unit  number  type  of  exposure  location  vehicle  vreapon  sensor 

*  name  combatant  name  name  name 

COMPANY  2  Defender  HD  4000.  BRAD  TOW2  AMTAS 

RECON  4  Defender  HD _ 4S00.  HMMWV  COAX  ANTAS 

Figure  4  Unit  Deployment  File 


Tha  first  antry  on  aach  lina  is  tha  unit  naaa.  This  naaa  is 
uaad  to  distinguish  combatants  in  this  unit  from  thosa  in  othar 
luiits.  All  output  will  ba  shown  in  rafaranca  to  thasa  unit  namas. 
Following  tha  unit  nama  is  tha  numbar  combatants  in  this  unit. 

Tha  nazt  two  antrias  ara  tha  typa  of  combatant  and  tha 
axposura.  For  tha  typa  of  combatant  thara  ara  thraa  choicas, 
Pafandar.  Attackar.  and  Ovarwatch.  Tha  amposura  of  tha  units  is 
aithar  hull  dafiladatHD)  or  fully  amposad(£E).  Both  dafanding  and 
owarwatch  units  ara  stationary,  and  can  ba  aithar  HD  or  FB. 
Dafandars  will  bagin  firing  upon  dataetion  wharaas  units  in 
ovarwatch  can  deploy  tha  tactic  that  thay  will  not  angaga  until  an 
anamy  vahicla  has  begun  tha  battle  (ovarwatch  tactic  is  sat  in  tha 
army  fila) .  Attackers  ara  moving,  and  should  ba  fully  amposad. 
For  a  stationary  engagement  both  forces  ara  stationary,  one  force 
will  consist  of  all  dafandars,  and  tha  othar  will  ba  all  ovarwatch. 
For  an  attack  scenario,  tha  attacking  force  will  consist  of 
attacker  units  and  ovarwatch  units  against  dafanding  units. 

Tha  next  input  is  tha  location  of  tha  units  on  tha  battlefield 
in  maters.  Bacausa  of  tha  way  tha  modal  keeps  track  of  tha  units, 
attackers  move  in  tha  positive  direction.  For  aza^pla,  if  tha 
battle  is  a  BLUE  attack  and  the  initial  battle  range  is  4000 
maters,  tha  RED  defense  would  ba  placed  at  4000.  and  tha  BLUE 
attackers  would  ba  started  at  0  maters.  Ovarwatch  units  can  ba 
placed  at  any  range. 

Tha  names  of  tha  vehicle,  weapon  and  tha  sensor  associated 
with  tha  units  ara  tha  last  thraa  inputs.  Thasa  names  will  ba  used 
in  the  othar  input  files  and  tha  names  must  match.  Tha  different 
vahiolas,  weapons,  and  sensors  can  ba  mixed  between  tha  different 
units  as  is  shown  in  tha  example. 
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IX. C  V«hiol«  Description  File 

The  vehicle  description  files  contain  the  data  which  describe 
the  platfoms  which  will  be  simulated.  The  file  describes  such 
things  as  the  physical  sise,  and  the  speed  of  the  vehicles.  For 
each  army  there  is  one  vehicle  file  which  contains  subunits  for 
each  vehicle  for  that  army.  The  BLDB  vehicle  file  is  bveh,  and  the 
RBD  file  is  rveh.  Each  subunit  has  the  same  structure,  and  the 
subunits  can  be  entered  in  the  file  in  any  order.  The  vehicle 
names  used  in  this  file  must  agree  with  those  specified  in  the  unit 
deployment  file. 

Figure  5  shows  the  structure  of  the  vehicle  subunit.  Bach 
subunit  can  begin  with  description  or  comment  lines  to  denote  what 
this  vehicle  is  (is.  ***  MlAi  or  ***  MlAi  with  20  percent 
signature  reduction) .  The  lines  in  the  sample  which  begin  with  '*» 
**  must  remain  in  the  file  or  an  error  will  result.  They  are 
included  to  help  the  user  when  entering  the  data. 


Comment  Lines 
/ehicle  Name 

-‘“Turret  dimensions:  Height  ifHidth  Length:  Front  Back 

x.x  x.x  x.x  x.x 

—Hull  dimensions:  Height  HWidth  Length:  Front  Back 

x.x  x.x  x.x  x.x 

—Target  Acq.  Data:  Hull  Defiladed,  Fully  Exposed 

x.x  x.x  *  Optical  Contrast 

x.x  x.x  *  Thermal  Contrast 

x.x  x.x  *  Critical  Dimension 

x.x  x.x  *  Radar  Cross  Section 

— Movement:  max  speed,  acceleration,  deceleration 
x.x  x.x  x.x 

—Times  to  Leave  the  Battle:  Jockey,  Nhen  Empty,  When  F-killed 

XX. X  XX. X  XXX. X 

—Active  Protection:  Arc  of  Protection,  Number  of  Launches 

XX. X  XX 

Weapon  Name 

—  P(det)  P(fire)/hit  P<fire)/miss  P(intercept) 
x.xx  x.xx  x.xx  x.xx 

—  Degradation  Factors:  0“,30*,60*,90«,120*,150»,180» 
x.xx  x.xx  x.xx  x.xx  x.xx  x.xx  x.xx 

END 

— ‘SiBoke  Grenades:  Ngren,  P(Launch),  alpha*CL's,  Time  to  Deploy,  Duration 

XX  x.x  x.x  x.x  x.x  XX. X 

— Laser  Warning  Recvr:  On/Off,  P(det),  Pop-smoke,  Engage,  Hide,  Nfov,  Tsearcl' 

T/F  x.x  T/F  T/F  T/F  x.x  x.x 


Length:  Front 
x.x 

Length:  Front 
x.x 


Back 

x.x 

Back 

x.x 


Figure  S  Vehicle  Description  File 


Ths  first  datm  that  ara  aaadad  ara  box  dimaasioBs  of  tha 
vahicla.  Tha  first  lias  is  for  tha  turrat  aad  tha  sacoad  for  tha 
hull.  Tha  dimaasioBs  raquirad  ara  tha  haight,  %  tha  width,  tha 
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front  length  (from  the  center  of  the  turret  ring  to  the  front  of 
the  vehicle) ,  and  the  back  length  (all  dimensions  are  in  meters)  . 

The  second  section  of  input  is  used  for  target  acquisition  and 
the  characteristics  entered  describe  the  appearance  of  this  vehicle 
to  others.  The  data  which  are  needed  are  the  optical  contrast, 
thermal  contrast,  critical  dimension,  and  radar  cross  section. 
Each  of  these  characteristics  is  entered  for  when  this  vehicle  is 
hull  defiladed  and  fully  exposed.  Optical  contrast  is  used  when  a 
visual  sensor  is  looking  at  this  vehicle.  It  is  defined  as  the 
difference  between  the  average  luoiinance  of  the  vehicle  and  the 
average  luminance  of  the  background  divided  by  the  average 
luminance  of  the  backgro\ind.  Thermal  contrast  is  merely  the 
difference  between  the  average  ten^rature  of  the  vehicle  and  the 
average  teo^rature  of  the  backgro\uid  (‘Celsius)  .  The  critical 
dimension  is  used  for  both  vistial  and  thermal  sensors  and  is 
usually  the  presented  height  of  the  vehicle.  Radar  cross  section 
is  used  when  the  opposing  sensor  is  a  radar  acquisition  device. 

The  user  then  enters  the  speed,  the  acceleration,  and  the 
deceleration  of  the  vehicle.  Even  if  the  vehicle  is  to  be 
stationary  in  the  battle,  the  user  should  enter  a  non-xero  speed. 
The  last  entry  on  this  line  controls  the  movement  of  attackers  when 
engaging  and  is  referred  to  as  pause.  If  an  attacker  is  engaging 
a  target  and  line  of  sight  is  about  to  break,  they  would  normally 
continue  advancing  and  discontinue  the  engagement.  Changing  this 
variable  to  a  1  causes  the  attacker  to  continue  the  engagement  by 
moving  to  a  hull  defiladed  posture  and  not  breaking  line  of  sight. 

During  the  battle  certain  situations  may  cause  a  vehicle  to 
try  to  leave  the  battlefield.  The  first  of  these  situations  is 
when  a  defender  or  overwatch  vehicle  pops  down  to  move  to  a  new 
position  or  to  reload  a  missile  pod.  The  second  is  when  a  unit  is 
depleted  of  ammunition  and  tries  to  move  to  a  fully  defiladed 
posture  to  avoid  being  killed.  The  third  situation  is  when  a  unit 
has  been  fire^power  killed  and  can  no  longer  participate  in  the 
battle  and  tries  to  hide.  A  certain  period  of  time  to  get  to  cover 
will  be  assessed  for  each  of  these  situations.  The  times  are 
entered  on  the  next  line  for  each  of  these  situations, 
respectively.  These  are  mean  times;  the  model  will  draw  from  a 
normal  distribution  about  these  times  to  determine  the  exact  time 
for  a  given  point  in  the  battle. 

The  last  sections  of  the  subunit  define  the  survivability 
enhancements  present  on  this  vehicle.  The  first  section  is  for  an 
active  protection  system  which  detects,  and  possibly  changes  the 
effectiveness  of  an  incoming  projectile.  The  system  protects  an 
arc  centered  at  the  front  of  the  vehicle  and  may  be  deployed  a  set 
number  of  times.  The  user  defines  the  arc  and  the  number  of  times 
it  may  activate  on  the  first  line.  The  system  works  in  four 
stages:  detection,  fire,  intercept,  and  degrade.  Probabilities  are 
used  to  define  the  first  three  stages. 
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It,  and  only  if,  the  nximber  of  times  the  system  may  activate 
is  greater  than  0  the  user  needs  to  enter  the  additional 
information  which  defines  the  system.  The  first  entry  is  the  name 
of  a  weapon  against  which  the  APS  will  activate.  The  next  line  of 
data  requires: 

P(det)  -prob.  of  detecting  the  incoming  rotind 

P  (fire) /hit  >prob.  of  firing  at  an  incoming  round  that  will  hit 
P (fire) /miss  -prob.  of  firing  at  an  incoming  round  that  will  miss 
P (intercept)  -prob.  of  intercepting  the  incoming  round. 

The  last  line  defines  the  degradation  factors  for  each  30  degree 
sector  within  the  arc  of  protection.  These  factors  are  multiplied 
times  the  lethality  of  the  incoming  round  (ie.  if  P (kill) =.6  and 
deg.  factor-. 2  the  resultant  P(kill)=.12) .  These  three  lines 
(weapon  name,  probabilities,  and  degradation)  are  duplicated  for 
each  weapon  against  which  this  system  is  effective.  When  all 
affected  weapons  have  been  entered,  enter  "END"  as  the  next  line. 

The  next  survivability  enhancement  is  an  on  board  smoke 
grenade  system.  The  system  has  the  ability  to  detect  an  incoming 
rowd  and  to  deploy  a  smoke  cloud  aroxmd  the  target  vehicle  which 
affects  target  acquisition  by  and  of  this  vehicle.  The  first  two 
inputs  are  the  number  of  times  the  launcher  can  fire  and  the 
probability  that  the  system  will  detect  and  deploy.  The  next  three 
entries  are  the  levels  of  smoke  (alpha*CL)  values  which  affect  the 
three  types  of  sensors:  optical,  thermal,  and  radar  respectively. 
The  next  input  on  the  line  is  the  time  from  launch  of  the  grenades 
to  the  effective  formation  of  the  smoke  cloud  around  the  vehicle. 
The  last  datum  is  the  effective  duration  of  the  siBOke  cloud  from 
the  time  it  forms. 

The  last  survivability  enhancement  is  a  laser  warning  receiver 
(LWR)  system  which  may  be  activated  when  the  vehicle  gets  lased 
prior  to  being  engaged.  For  the  LWR  to  react,  the  engaging  weapon 
system  must  be  using  a  laser  range  finder.  The  first  entry 
determines  if  there  is  an  LWR  on  board,  either  True  or  False  (T/F)  . 
The  next  entry  is  the  probability  that  the  LWR  will  detect  that  it 
has  been  lased  and  that  it  will  react.  The  first  reaction  is  to 
pop  saioke  grenades.  If  popping  smoke  grenades  is  desired,  the  user 
needs  to  enter  the  appropriate  values  on  the  smoke  grenade  line. 
If  only  this  warning  receiver  is  to  trigger  smoke  grenades,  the 
.  probability  of  sensing  on  the  smoke  grenade  line  should  be  set  to 
0.0.  The  next  reaction  to  being  lased  is  to  turn  and  engage  the 
ccMBbatant  who  lased  you.  The  last  reaction  is  to  try  to  hide.  Any 
combination  of  these  reactions  can  be  played  simultaneously.  When 
the  LWR  reaction  is  to  turn  and  engage,  the  LWR  can  give  different 
levels  of  acctiracy  when  pointing  in  the  direction  of  the  threat. 
If  the  LWR  can  give  a  precise  location  of  the  enen^,  the  entry  for 
the  next  input  is  1.0.  Otherwise  the  user  should  enter  the  general 
area  to  search  for  the  threat  as  a  number  of  fields  of  view  of  the 
appropriate  sensor.  The  last  entry  on  the  line  is  the  time  to 
search  for  this  enen^  before  resuming  normal  search. 
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II. D  Weapon  Description  File 

As  with  the  vehicle  description  file,  there  is  a  BLUE  weapons 
file  (bweap)  and  a  RED  weapons  file  (rweap)  .  The  file  contains 
subunits  which  describe  one  weapon  system  each.  For  each  weapon 
subunit  the  user  defines  firing  times,  reliability,  times  to 
reload,  type  of  round  etc.  The  general  structure  of  the  subtmit  is 
shown  in  Figure  €.  The  first  data  entry  is  the  name  of  the  weapon 
system  (character  string)  which  must  agree  with  one  of  the  weapon 
systems  named  in  the  \init  deployment  file. 


**  Comment  Line(s) 

Weapon  Name 
— Type  Max .  Range 

Nrounds 

Halt-fire  Tactic  Nrpt  LRF 

XX  xxxx . 

XX 

X  X  XX  X 

— Inputs  by  Range;  P (sense),  T (flight),  T (first),  T(fixed),  Rel. 

X  .  XX  X  .  XX  X  .  XX 

X . XX  ... 

X.XX  x.xx  **  P(sense) 

XX. X  XX. X  XX. X 

XX .X  . . . 

XX. X  XX. X  **  T(flight) 

XX. X  XX. X  XX. X 

XX . X  ... 

XX. X  XX. X  **  T(first) 

XX. X  XX. X  XX. X 

XX . X  . . . 

XX. X  XX. X  **  T(fixed) 

X  .XX  X  .XX  X  .XX 

x.xx  . . . 

x.xx  x.xx  **  Reliability 

— Jockeying:  IF-pop 

N  ( jockey) 

T(  jockey) 

X 

XX 

XX.  X 

— Subsequent  Firing: 

T (median) 

T(min) 

x.x 

x.x 

— Burst  Fire:  Rate-Fire  Nrds /Burst 

X  .X 

X 

— Missiles:  IF-dis  Nipods  Ntgts  T (reload)  Pabt/smk  Pabt/terr 

X 

X 

X  XX. X  x.xx  x.xx 

— Multiple  Engagement 

IF-mult 

T(mult)  N(mult)  Reload-part 

X 

XX .X  X  X 

Figure  6  Weapon  Description  File 


On  the  next  line  the  user  defines  the  type  of  round  being 
fired.  The  table  below  shows  the  appropriate  inputs  for  the  four 
types  of  rounds.  Next  the  user  enters  the  maximum  effective  firing 
range  of  the  weapon  and  the  total  number  of  rounds  on  board  the 
vehicle.  The  last  input  on  the  line  determines  if  this  weapon 
system  halts  before  firing.  The  system  will  halt  before  firing  if 
«  the  user  enters  a  1. 


Kinetic  Sn^gy  Rimd  (XE)  1 

High  ioqplosive  (aSKT)  a 

Fire  and  Forget  Missile  (F3VF}  ,  3 


CfiemMid  Line'*-of~B4'^t  Missile  4 


Table  1  Round  Type  Assignment  Numbers 
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Disengagement  policy  is  governed  by  the  next  input,  tactic. 
The  follotring  table  shows  the  different  policies  and  their 
corresponding  numerical  inputs.  The  user  should  set  tactical  to 
disengage  only  if  the  target  is  catastrophically  killed.  If  the 
f irer  should  disengage  for  one  of  the  other  reasons  the  appropriate 
number  from  the  table  should  be  used.  If  the  firer  is  to  disengage 
after  a  set  nundaer  of  shots,  the  number  of  shots  to  fire  is  the 
last  input  on  the  line. 


biaeogage  After:  :  - 
;  1 

Bitting  the  Target  2 

Tiring  Nxpt  Sounds  at  the  Target  3 


Table  2  Disengagement  Tactics 


The  last  entry  on  this  line  determines  if  'Lnis  weapon  system 
uses  a  laser  range  finder  prior  to  its  first  round  of  an 
engagement.  The  play  of  the  range  finder  does  not  change  the  way 
accuracy  is  played.  The  only  effect  of  setting  this  input  to  True 
is  that  it  will  now  activate  laser  warning  receivers  on  target 
vehicles . 

The  next  five  lines  are  data  which  are  input  by  range.  These 
data  are  input  in  range  increments  as  specified  in  the  game  control 
file.  The  first  value  on  each  line  should  be  for  range-increment, 
not  for  rangesQ  meters.  There  must  be  enough  numbers  on  each  line 
to  cover  up  to  and  including  the  maximum  firing  range  set  on  line 
1.  The  first  line  is  the  probability  that  the  firer  will  sense  the 
impact  location  of  a  round  that  misses  its  target,  P (sense). 
T (flight)  is  the  time  of  flight  of  the  round  to  the  various  ranges. 
The  median  time  to  fire  the  first  round  of  an  engagement,  T  (first) , 
is  next.  T (fixed)  is  the  fixed  time  between  rounds  when  using  an 
auto-loader.  The  last  input  which  is  a  function  of  range  is  the 
reliability  of  the  roiind. 

Groundwars  allows  systems  which  are  either  in  defense  or 
overwatch  to  increase  survivability  by  moving  to  a  fully  defiladed 
posture  at  certain  points  in  the  battle.  A  missile  system  which  is 
reloading  its  missiles  may  pop  down  to  complete  this  siission  by 
setting  if-ppp  ^  i,  a  KE  system  may  pop  down  and  move  to  a  new 
position  (jockey)  after  firing  a  set  number  of  shots,  N( jockey) .  If 
N( jockey)  is  equal  to  0  for  a  KE  weapon,  the  unit  will  not  jockey. 
The  length  of  time  a  KE  system  remains  fully  defiladed  is  defined 
by  the  input  T(  jockey) .  Missile  systems  remain  fully  defiladed  for 
the  reload  time,  T (reload),  mentioned  later. 

The  next  line  characterizes  the  subsequent  firing  times  for 
the  system.  The  \iser  inputs  the  median  time  to  fire  a  subsecpient 
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round  and  a  mininnim  time  to  fire.  Before  a  subsequent  round  is 
fired,  a  random  draw  is  made  from  a  loq-normal  distribution  about 
the  median  time  to  determine  the  random  re-aiming  time.  This  time 
is  added  to  the  fixed  time  between  rounds  if  an  auto-loader  is 
being  used.  If  this  total  time  is  less  than  the  minimum  time,  then 
the  minimum  time  to  fire  a  subsequent  round,  T  (min) ,  will  be  used 
as  the  subseq[uent  firing  time. 

The  next  line  defines  attributes  for  within  burst  rounds.  The 
first  input  is  the  rate  of  fire  in  rounds  per  second.  The  second 
input  is  the  number  of  rounds  in  a  single  burst. 

A  number  of  inputs  are  required  for  missile  systems .  For 
missile  systems  which  remain  exposed  during  reload  (if-pop=0) , 
there  are  two  choices  for  continuing  an  engagement.  The  system  may 
be  able  to  keep  its  fix  on  its  target  and  therefore  resume  the 
engagement  of  that  target  upon  finishing  reloading.  On  the  other 
hand,  some  systems  such  as  hand-held  one  person  systems  cannot 
maintain  a  fix  on  the  target  and  must  begin  the  acquisition  process 
anew  after  reloading.  If  the  system  can  maintain  a  fix  on  the 
target  while  reloading  then  if-dis  should  be  set  to  0,  otherwise 
set  it  to  1  . 

The  next  input  is  the  number  of  missiles  on  board  which  are 
ready  to  fire.  It  is  this  number  which  will  be  reloaded  when  the 
ready  rounds  are  depleted.  Ntgts  is  the  number  of  rounds  which  can 
be  fired  nearly  simultaneously  (should  be  set  to  1  when  not  playing 
multiple  engagement)  .  T  (reload)  is  the  time  required  to  reload  the 
ready  to  fire  missile  p^.  The  next  two  data  are  probabilities 
that  a  missile  will  abort  due  to  a  change  in  the  atmosphere 
(smoke) ,  and  to  line  of  sight  breaking  between  the  firer  and  target 
during  flight. 

The  last  section  of  each  subunit  deals  with  a  missile  system's 
ability  to  queue  targets  and  fire  at  them  nearly  simultaneously. 
A  system  may  only  play  multiple  engagement  if  the  round  type  is  a 
fire  and  forget  siissile.  If  multiple  engagement  is  desired,  if-mult 
should  be  set  to  1.  T(mult)  is  the  time  from  initial  detection  to 
search  for  additional  targets  before  beginning  the  engagement . 
After  t(mult}  has  elapsed  the  firer  will  begin  the  engagement. 
N(mult)  is  the  total  number  of  targets  to  try  to  multiply  engage. 
After  n(mult)  targets  have  been  detected,  the  firer  will  fire  a 
-  single  shot  at  each  target  and  disengage.  When  playing  siultiple 
engagement,  a  system  is  able  to  reload  part  of  its  siissile  pod  so 
that  it  always  has  a  full  pod  when  engaging  targets.  Reload-part 
should  be  set  to  1  if  the  system  can  reload  part  of  the  pod,  and 
that  is  the  desired  tactic. 
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IX. S  8«nsor  Ottscriptlon  Fil* 

Oroundwars  allows  tbs  usar  to  play  optical,  tharaal,  or 
ailliastar  wave  daviess,  with  a  total  of  c  sansors  for  both  sidas. 
As  with  tha  wahiela  and  waapon  filas,  tha  saasor  fila  is  a  group  of 
subunits,  ona  for  aaoh  sansor.  Tha  BLUB  sansor  fila  is  nanad 
bsans,  and  tha  RED  is  mans. 

Tor  optical  and  thanal  davicas,  tha  nodal  usas  a  form  of  tha 
CCRVEO  (CECOK  Cantar  for  Might  vision  and  Blactro-optics)  target 
acquisition  nathodology  to  approxinata  acquisition  capability.  Tha 
play  of  nillinatar  wava  tachnology  in  tha  nodal  is  linitad  and  tha 
parfomanca  of  this  typa  of  sansor  is  fixed  except  for  changes  in 
tha  atnosphara.  Tha  required  data  for  optical  and  thamal  devices 
is  different  fron  that  for  a  radar  device,  so  tha  structures  of  tha 
subunits  for  tha  two  types  will  be  explained  separately. 


**  Coimnent  Line(s) 

Sensor  Name 

—  Sensor  Type:  VISUAL  or  THERMAL 

—  Data  Type:  TWENTY  or  NVLEXP 
--  Sensor  Data 

If  data  type  •  TWENTY,  enter  2  twenty  point  curves 

a.  Hlnimum  Resolvable  Contrast  or  Temperature 

b.  Spatial  Frequency 

If  data  type  >  NVLEXP,  enter  7  coefficients 

—  Horizontal  and  Vertical  Fields  of  View  and  Search 

XX. X  XX. X  XX. X  XX. X 

Magnification  and  Level  of  Acquisition 
x.x  x.x  x.x 

—  N(dets),  p(falee)  (HO,FE} 

X  x.xx  x.xx 

—  Pinpoint  prob  against  all  red  weapons 

weaponl  x.xx 
weapon2  x.xx 
weapon3  x . xx 

END _ 

Figure  7  VISUAL  and  THERMAL  Sensor  Subunit 


Ths  figure  above  shows  the  structure  of  the  sensor  perforaance 
subunit  for  optical  and  theraal  sensors.  The  first  four  lines  of 
data  req[uire  character  strings  for  input.  The  first  line  is  the 
sensor  naae.  On  the  first  line  of  data  the  user  specifies  either 
VIBUAL  or  THERMAL.  The  type  of  data  for  these  types  of  sensors  can 
be  input  in  one  of  two  ways  with  inputs  of  TWBMTY  and  MVLBIP.  For 
TMEMTY  the  user  enters  two  perforaance  curves  which  contain  twenty 
points  each  (apparent  contrast  and  then  spatial  frequency) .  For 
MVLEIF  the  user  enters  seven  coefficients  to  fit  a  sixth  degree 
polynoaial. 

For  the  rest  of  the  subunit,  there  will  first  be  a  description 
line  and  then  a  data  line.  As  with  the  vehicle  and  weapon  file. 
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tli«  eouMt  lin«8  which  ar«  shown  with  " — "  wust  rawain  in  tha 
fila.  On  tha  naxt  lina,  antar  tha  horisontal  and  vartical  fialds 
of  viaw  and  fialds  of  saarch.  Tha  fialds  of  viaw  ara 
oharaotaristie  of  tha  sansor,  and  tha  fialds  of  saarch  ara  basad  on 
battlafiald  rasponsibility.  Tha  naxt  lina  raquiras  tha 
■agnification  of  tha  sansor  and  tha  laval  of  acquisition  dasirad 
against  stationary  tar gats,  and  against  moving  tar gats. 

On  tha  naxt  lina  tha  usar  spacifias  tha  nuabar  of  targats 
which  may  ba  datactad  eoncurrantly  (huntar-killar)  by  a  systam  with 
this  sansor,  H(dats).  If  this  systam  must  ramain  fixad  on  tha 
targat  whila  tha  gunnar  sarvicas  tha  targat,  n(dat8)  should  ba  sat 
to  1.  If  othar  targats  can  ba  datactad  whila  tha  gunnar  is  busy, 
n(dat8)  should  ba  sat  >  i. 

Also  on  this  lina  ara  two  probabilitias  of  datacting  falsa 
targats,  P (falsa).  Whan  a  targat  is  first  datactad,  a  random  draw 
is  mads  against  thasa  probabilitias  to  saa  if  a  falsa  targat  will 
ba  randomly  aubstitutad  for  tha  raal  targat.  Tha  first  probability 
is  for  whan  tha  obsarvar  datacts  a  hull  dafiladad  targat,  and  tha 
saeond  is  for  fully  axposad  targats. 

Tha  last  saction  of  tha  subunit  dafinas  tha  probabilitias  of 
this  sansor  dotacting  tha  firing  signaturas  of  othar  waapons  in  tha 
battla.  On  aach  lina  antar  tha  opposing  waapon  nama  and  tha 
probability  of  dataction  givan  tha  waapon  firas.  Whan  all  dasirad 
waapon  hava  baan  input,  antar  **B1ID*'  to  and  tha  saction. 

Tha  figura  to  tha  right 
shows  tha  structura  of  tha 
sansor  subunit  for  a  radar 
sansor.  Tha  usar  spacifias 
RADAR  as  tha  sansor  typa.  Only 
rain  and  cluttar  affact  radar 
acquisition.  If  thara  is  no 
rain,  tha  input  is  a  0,al8a  it 
is  a  1.  On  tha  sama  lina,  tha 
laval  of  cluttar  is  spacifiad, 
and  can  ba  aithar  low  cluttar 
(1.0),  or  highar  cluttar 
(>1.0).  Tha  final  saction  of 
«  tha  subunit  is  tha  sama  as  for 

visual  and  tharmal,  from  tha  numbar  of  datactions  to  tha  and  of  tha 
subunit . 


**  Comnent  Lin8(8) 

Sensor  Name 

—  Sensor  Types  RADAR 

—  IF-rain,  Clutter 

X  x.x 

—  N(det8),  P(fal8e) 

X  x.xx  x.xx 

—  Fire-signature  prob.'s 

vreaponl  x.xx 

weapon2  x . xx 

weapons  x .  xx 

END _ 

Figure  8  RADAR  Sensor  Subunit 
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II. F  Weapon  Accuracy  File 

For  each  weapon  system  defined  in  the  two  unit  deployment 
files,  there  must  be  a  file  which  contains  weapon  system  delivery 
accuracies .  BLUE  accuracy  files  have  the  form  bacc?  where  ?  starts 
at  1  and  ends  at  the  number  of  blue  weapon  systems.  The  same 
structure  holds  for  all  RED  accuracy  files  (race?) .  Each  file  has 
the  structure  shown  in  Figure  9.  The  model  requires  biases  and 
errors  for  three  situations:  stationary  firer  against  a  stationary 
target,  a  stationary  firer  against  a  moving  target,  and  a  moving 
firer  against  a  stationary  target.  The  ouddel  does  not  require 
errors  for  a  moving  firer  against  a  moving  target. 

The  file  is  free  formatted,  and  all  lines  which  begin  with  an 
***"  are  comment  lines  included  for  clarity;  comment  lines  may  be 
added  or  removed  between  groups  of  data,  but  not  within  a  group  of 
data.  All  ranges  are  in  meters,  and  all  biases  and  errors  are  in 
mils  (1/6400  of  a  circle) . 

There  exist  three  types  of  errors  which  are  read  into  the 
model  and  can  be  classified  according  to  how  long  they  persist. 
Fixed  biases  are  those  which  persist  over  many  engagements . 
Variable  biases  are  caused  by  transient  effects  such  as  cross  wind. 
Random  errors  are  those  which  change  from  round  to  round  and  are 
caused  by  differences  in  individtaal  rounds,  wind  gusts,  etc. 

The  first  two  lines  of  each  file  must  contain  a  weapon  name 
and  the  number  of  range  increments  which  will  be  input.  The  range 
input  must  account  for  all  ranges  from  0  up  to  and  inclxiding  the 
maximum  firing  range  of  the  weapon. 

The  first  section  of  the  file  is  for  a  stationary  firer 
against  a  stationary  target.  For  this  sitiiation  data  is  required 
for  the  first  round  fired  and  for  subsequent  rounds.  For  first 
rounds,  fixed  bias,  variable  bias  and  random  error  are  required. 
For  subsequent  rounds  only  random  error  is  needed.  This  error 
varies  depending  on  whether  the  previous  shot  was  a  hit,  a  lost 
miss ,  or  a  sensed  miss .  Misses  are  either  lost  or  sensed  depending 
,  on  the  value  of  p (sense)  in  the  weapon  description  file.  For  the 
.  number  of  ranges  to  be  input,  the  user  will  enter  a  range  and  its 
corresponding  errors  for  first  and  subsequent  rounds. 

The  second  section  of  the  file  is  for  a  stationary  firer 
against  a  moving  target.  This  section  has  only  two  types  of  error: 
fixed  bias  and  total  error.  These  errors  are  required  for  four 
different  attack  angles:  0,  30,  60,  and  90  degrees  as  is  shown  in 
the  figure. 

The  third  section  is  for  a  moving  firer  against  a  stationary 
target .  Only  fixed  bias  and  total  error  are  required  at  each  range . 
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**  Comment  Line(s) 

Weapon  Name 
6  ranges 

****  STATIONARY  FIRER  vs  STATIONARY  TARGET  *  * ** 


1st  Round -  - sub.  rounds - - 

h/h  h/lm  h/sm 


fix 

bias 

var 

bras 

ran 

err 

ran 

err 

ran 

err 

ran 

err 

rang 

H 

V 

H 

V 

H 

V 

H 

V 

H 

V 

H 

V 

rngl 

1 

.XXX 

1 

.XXX 

1 

.  XXX 

1 

.XXX 

1 

.XXX 

1 

.  XXX 

1 

.XXX 

1 

.  XXX 

1 

.XXX 

1 

.  XXX 

1 

.XXX 

1 

.XXX 

1 

1 

rngN 

1 

.XXX 

1 

.  XXX 

1 

.  XXX 

1 

.XXX  . 

1 

.  XXX 

1 

.XXX 

1 

.XXX 

1 

.  XXX  , 

1 

.  XXX  , 

1 

.  XXX  , 

1 

.  XXX 

1 

.  XXX 

****  STATIONARY  FIRER  vs  MOVING  TARGET 


0 

degrees 

fixed 

bias 

total 

error 

rg 

(m) 

H 

V 

H 

V 

rngl 

1 

.  XXX 

1 

.XXX 

1 

.  XXX 

1 

.XXX 

1 

4 

1 

rngN 

1 

.XXX 

1 

.XXX 

( 

.XXX 

1 

.  XXX 

* 

30 

degrees 

fixed 

bias 

total 

error 

•it 

rg 

(m) 

H 

V 

H 

V 

rngl 

1 

.  XXX 

1 

.  XXX 

1 

.XXX 

1 

.XXX 

1 

* 

1 

rngN 

1 

.  XXX 

1 

.XXX 

1 

.  XXX 

1 

.XXX 

* 

60 

degrees 

fixed 

bias 

total 

error 

* 

rg 

(m) 

H 

V 

H 

V 

rngl 

1 

.  XXX 

1 

.XXX 

1 

.XXX 

1 

.XXX 

i 

* 

1 

rngN 

1 

.XXX 

1 

.  XXX 

1 

.XXX 

1 

.  XXX 

* 

90 

degrees 

fixed 

bias 

total 

error 

♦ 

rg 

(m) 

H 

V 

H 

V 

rngl 

1 

.  XXX 

1 

.  XXX 

i 

.XXX 

1 

.XXX 

1 

* 

1 

rngN 

1 

.  XXX 

1 

.XXX 

1 

.  XXX 

1 

.  XXX 

moving  FIRER  vs  STATIONARY  TARGET 

♦  *  *  4 

fixed  bias 

total  error 

-* 

rg 

(m) 

H 

V 

H 

V 

rngl 

1 

.XXX 

1 

.  XXX 

1 

.XXX 

1 

.XXX 

i 

1 

rngN 

1 

.XXX 

1 

.XXX 

1 

.XXX 

1 

.XXX 

rigur*  9  Weapon  Accuracy  File 


20 


II. 6  Lethality  Files 


The  lethality  files  contain  probability  of  kill  information 
which  can  be  entered  as  either  the  Probability  of  Kill  given  a  Hit 
(PKH)  or  as  the  Probability  of  Kill  given  a  Shot  (PKS)  . 
Probabilities  of  kill  are  generated  by  the  Vulnerability/Lethality 
Division  of  the  Ballistic  Research  Laboratory  (BRL) .  The  names  of 
these  files  in  the  current  working  directory  are  similar  to  those 
for  the  accuracy  files.  BLUE  files  have  the  prefix  bpk,  and  RED 
files  begin  with  rpk.  The  BLUE  files  will  be  named:  bpkl,  bpk2, 
...,  bpklO,  l^kll,  ...  PK  files  must  exist  for  evoory  combination 
of  weapon  system  and  vehicle  which  the  user  wishes  to  have  fight . 
The  model  checks  to  see  if  all  combinations  of  weapons  vs.  vehicles 
have  been  entered  (including  BLUE  vs.  BLUE  and  RED  vs.  RED)  .  For 
those  that  do  not  exist,  the  model  will  give  a  warning  message. 
The  user  should  check  these  warnings  for  the  first  runs  of  the 
study  to  be  sure  tl.at  no  desired  combination  has  be  missed. 

The  model  recognizes  four  levels  of  kill:  mobility  kill,  fire¬ 
power  kill,  mobility  and  fire-power  kill,  and  catastrophic  kill. 
The  four  levels  of  kill  have  the  following  results  in  the  model . 
A  mobility  kill  renders  an  attacker  unable  to  continue  the  attack; 
the  combatant  remains  at  its  current  exposure  and  range,  and  can 
still  engage.  For  a  defender  or  overwatch  unit,  a  mobility  kill 
means  that  it  no  longer  may  pop  down  to  reload  or  jockey  to  an 
alternate  position.  A  fire-power  kill  leaves  the  combatant  unable 
to  fire,  and  he  atteo^ts  to  reach  cover  to  avoid  being  killed 
further.  For  a  mobility  and  fire-power  kill,  the  combatant  can  no 
longer  fiinction,  but  it  is  not  totally  destroyed.  Vehicles  which 
have  sustained  one  of  these  levels  of  damage  continue  to  draw  fire, 
and  may  be  killed  at  a  higher  level.  A  catastrophically  killed 
combatant  no  longer  functions,  and  all  units  know  that  it  no  longer 
is  a  threat. 

The  first  section  of  every  file  contains  the  same  information, 
whether  the  user  uses  PKH  or  PKS.  On  the  first  line  the  weapon 
name  and  the  target  vehicle  name  are  given;  these  must  agree  with 
those  input  in  the  unit  deployment  files.  On  the  second  line  two 
flags  are  set  which  dictate  the  form  of  the  lethality  data.  The 
first  flag  determines  if  the  data  is  entered  as  PKH  or  PKS  data. 
If  the  flag  is  set  to  a  0  or  a  2  the  data  is  PKS  data.  If  the  flag 
is  a  1  the  data  is  PKH.  The  forms  of  these  data  will  be  described 
shortly. 

The  second  flag  on  the  line  determines  if  the  data  is 
independent  of  range  to  the  target.  For  some  weapons  the  lethality 
of  the  weapon  is  the  same  at  all  ranges.  A  0  designates  lethality 
which  is  a  function  of  range  and  a  1  designates  range  independent 
lethality . 
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The  first  two  forms  of  data  are  probability  of  kill  given  a 
shot.  The  data  for  both  forms  are  independent  of  target  aspect 
angle  and  round  dispersion.  The  two  forms  require  the  same  data, 
but  are  entered  in  a  different  order.  For  both  forms,  the  data 
should  begin  with  range  of  0  meters.  If  the  first  lethality  flag 
is  set  to  a  0,  the  data  needs  to  be  in  the  form  sho%m  in  Figure  10. 
When  the  flag  is  set  to  a  2,  the  data  needs  to  be  in  the  form  shown 
in  Figure  11.  When  P(k/s)  data  is  being  used,  the  probability  of 
hit  is  forced  to  be  1.0  within  the  model,  since  the  probability  of 
hit  was  factored  into  the  calculation  of  the  P(k/s)  . 


•*  Comment  Line(s) 

Weapon  Name  Ta’'get  Name 

0  X  lethality  flags 

**  0  m  rng2  rng3  rng4 

rngN  1 

Kill  Type 

**«'***'•**•«** 

1 

* 

F.xposure 

X  .XX 

X.XX 

X.XX  X.XX  ... 

X.XX  1 

M  Kill 

1 

HD 

X  .XX 

X.XX 

X.XX  X.XX  ... 

X.XX  1 

F  Kill 

1 

HD 

X.XX 

X.XX 

X.XX  X.XX  ... 

X.XX  1 

M&F 

Kill 

1 

HD 

X  .  XX 

X  .  XX 

X.XX  X.XX  ... 

X.XX  1 

Catastrophic 

1 

HD 

X.XX 

X  .  XX 

X.XX  X.XX  ... 

X.XX  1 

M  Kill 

1 

FE 

X.XX 

X.XX 

X.XX  X.XX  ... 

X.XX  1 

F  Kill 

1 

FE 

X.XX 

X.XX 

X.XX  X.XX  ... 

X.XX  1 

M  S  F 

Kill 

1 

FE 

Figure  10 

PKS  Lethality  File  (flag=0) 

*♦  Comment  Line(s) 

Weapon  Name  Target  Name 

2  X  lethality  flags 

**  M  F  M&F  K 

1  Range  1 

Exposure 

* 

X.XX 

X  .  XX 

X.XX  X.XX 

1  0  meters  1 

HD 

X.XX 

X.XX 

X.XX  X.XX 

1  range 

2  1 

HD 

X.XX 

X  .XX 

X.XX  X.XX 

1  range 

3  1 

HD 

X.XX 

X.XX 

X.XX  X.XX 

1  range 

i 

4  i 

1 

HD 

X.XX 

X.XX 

X.XX  X.XX 

t  range 

1 

N  1 

1 

HD 

X.XX 

X.XX 

X.XX  X.XX 

1  0  meters  1 

FE 

X.XX 

X.XX 

X.XX  X.XX 

1  range 

2  1 

FE 

X.XX 

X.XX 

X.XX  X.XX 

1  range 

3  1 

FE 

X.XX 

X.XX 

X.XX  X.XX 

1  range 

4  1 

1 

FE 

X.XX 

X.XX 

X.XX  X.XX 

1  range 

N  1 

FE 

Figure  11  PKS  Lethality  File  (flag*2) 


The  third  form  to  enter  the  data  is  the  Individual  Unit  Action 
(lUA)  file  as  produced  by  the  BRL.  For  this  type  of  input  data, 
the  first  lethality  flag  should  be  set  to  1 .  The  data  is  a 
function  of  target,  aspect  angle,  target  exposure,  round  dispersion 
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2md  kill  critaxia.  Tha  figura  balow  shows  tha  ganaral  structure 
of  this  file.  This  file  is  formatted,  and  should  be  received  from 
the  BRL  in  the  proper  format. 

For  each  range  there  is  a  group  of  88  lines  of  Pkh  data.  For 
lethality  which  is  independent  of  range,  there  will  be  only  one  set 
of  88  lines.  In  each  group  of  88  lines  there  are  44  lines  against 
a  hull  defiladed  target  followed  by  44  lines  for  fully  exposed 
targets.  In  each  group  of  44  lines  there  are  11  sets  of  4  lines. 
The  first  10  sets  of  lines  correspond  to  10  linear  dispersions 
(1-10  feet)  and  the  11th  set  is  for  a  uniform  distribution  of  shots 
on  the  target.  Each  of  the  four  lines  corresponds  to  one  of  the 
four  kill  categories. 


**  Comment  Line(s) 

Weapon  Name  Target  Name 
lx  **  lethality  flags 

***  range  E  D  K  0  30  60  90  120  150  180  Avg 

«-**'*'*'*ee-**««'**'*-ir'*e‘*'«e**tk«i^'**e***ee***«-***e«e*«e**eee**eee*‘*«e*««e* 

rngl  1  11  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 

rngl  1  12  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 

rngl  1  13  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 

rngl  1  14  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 

rngl  1  21  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 

rngl  1  22  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 

rngl  1  23  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 

rngl  1  24  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 

rngl  1  31  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 


rngN  2  10  3  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 
rngN  2  10  4  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 
rngN  2  11  1  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 
rngN  2  11  2  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 
rngN  2  11  3  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 
rngN  2  11  4  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx  x.xxx 


Definitions 

rngl  -  0  meters 

rngN  -  last  range  for  data 

E  -  Target  Exposure 

D  -  Dispersion  of  the  round,  1-10  ft.,  11  is  random  disp. 

K  -  Kill  type  (l-mkill,  2-fkill,  3-mfkill,  4-kkill) 

Target  Aspect  Angle  -  0,  30,  60,  90,  120,  150,  180  degrees 


Figure  12  lUA  Lethality  File 
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II. H  Army  Miscellaneous  File 

The  next  file  is  the  army  miscellaneous  file  which  contains 
information  that  isn't  specific  to  any  one  xinit  type.  An  army  file 
is  required  for  each  army.  The  names  of  the  two  files  are  barmy 
and  rarmy.  The  general  structure  of  the  file  is  sho%m  in  the 
figure . 


**  Comment  Line(s) 

— Tactics:  Priority 

T (relook) 

N(bump)  T(buinp)  Over-eng 

X 

XX  .X 

x  XX . X  X 

— Communications:  If 

-comm  P(pass)  T{pass)  T (search) 

X  X. 

XX  XX  .  x  XX  .  X 

— Decoys :  NAME 

N (flash) 

T(start)  T(flash) 

Unit  Name 

X 

XX. X  XX. X 

— IF  Artillery 

X 

Target 1 

— Prep.  Artil.  m 

f  m«f  k 

x.xx  x.xx 

x.xx  X.XX 

— On-call  Artil. 

m  f  msf  k 

x*xx  x.xx 

x.xx  X.XX 

Target2 

— Prep.  Artil.  m 

f  mif  k 

X.XX  x.xx 

x.xx  x.xx 

— On-call  Artil. 

m  f  m5f  k 

x.xx  x.xx 

x.xx  x.xx 

1  END 

Figure  13  Army  Miscellaneous  File 


The  first  line  of  the  file  requires  inputs  for  various 
tactical  decisions.  The  first  entry  is  for  target  priority.  If  a 
unit  is  able  to  detect  more  than  one  target  concurrently,  the  firer 
will  pick  older  targets  over  new  if  this  is  set  to  1,  and  newer 
targets  over  old  if  this  is  set  to  2.  If  the  wit  cannot  detect 
more  than  one  target,  this  input  will  have  no  effect. 

The  second  input  is  the  time  a  firer  will  search  for  other 
targets  before  going  back  to  a  previously  serviced  target  and 
renewing  the  engagement  (only  if  the  target  is  still  in  line  of 
sight  and  is  not  k-killed) . 

The  next  two  inputs  are  used  when  a  target  vehicle  is  mobility 
and  firepower  killed,  and  is  no  longer  functioning.  A  firer  will 
recognize  a  target  in  this  condition  as  non-threatwing,  and  will 
disengage  it.  The  firer  will  disengage  the  target  after  firing 
M(buii^)  rounds  at  it  or  after  waiting  T(bunp)  seconds.  Nhen  either 
of  these  conditions  is  met,  the  target  is  "btimped  up"  to  w 
inactivity  killed  vehicle,  and  all  units  will  disengage  it. 


The  last  input  on  this  line  governs  the  play  of  overwatch 
vehicles  in  the  simulation.  As  was  mentioned  in  the  wit 


deployment  file  section,  overwatch  vehicles  can  either  fire  as  soon 
as  they  acquire  a  target,  or  they  may  stay  quiet  until  the  enemy 
begins  to  fire.  If  the  overwatch  should  fire  upon  acquiring  a 
target,  this  input  is  a  1,  else  it  is  a  0. 

The  next  line  of  input  governs  the  play  of  communications 
between  friendly  vehicles.  When  one  unit  detects  an  enemy  unit,  it 
may  pass  the  enemy  unit's  location  to  others.  If  the  location  is 
received,  the  receiver  will  conduct  a  field  of  view  search  in  the 
area  amd  attesqpt  to  detect  the  target.  Enter  a  1  for  If-comm  to 
give  this  army  communications.  The  next  value  is  the  probability 
that  the  others  will  receive  the  transmission  of  the  target's 
location.  Next  is  the  time  to  wait  before  the  receiving  vehicle 
will  conduct  its  search.  The  final  entry  is  the  length  of  time  the 
receiving  vehicle  will  search  in  the  field  of  view  iMfore  renewing 
normal  search.  To  have  no  others  engage  this  same  vehicle,  the 
time  to  wait  before  searching  should  be  set  to  a  large  number.  To 
have  friendly  xmits  gang  up  on  the  detected  target,  set  this  wait 
time  to  0.0  . 

The  information  necessary  for  the  play  of  decoys  is  on  the 
next  line.  Decoys  are  entered  as  any  other  unit  type  in  the  unit 
deployment  file.  However,  the  vehicle,  weapon,  and  sensor  names 
should  be  set  to  "NULL" .  When  the  army  file  is  read,  the  name  of 
the  decoy  which  is  entered  here  is  used  to  make  all  imits  of  this 
type  decoys.  When  only  normal  decoys  are  played,  the  remaining 
inputs  on  this  line  should  be  set  to  0.  When  flashing  decoys  are 
played,  the  number  of  flashing  decoys  is  entered  next,  which  is  a 
8\]bset  of  the  total  number  of  decoys .  The  next  two  inputs 
determine  the  "when  to  start  flashing"  and  "how  often  to  flash"  for 
the  decoys.  Two  inputs  determine  the  'when'  and  'where'  for  decoys 
flashing.  Both  of  these  numbers  are  in  seconds.  The  first  is  the 
time  in  the  battle  when  the  decoys  should  begin  to  flash.  When 
flashing  decoys  are  played  the  user  must  enter  the  probability  of 
detecting  the  flashes  in  the  opposing  sensor  file. 

The  rest  of  the  file  is  for  the  play  of  artillery.  If 
artillery  is  not  desired,  a  0  can  be  input  on  the  next  line  and  no 
other  entry  need  be  made.  If  artillery  is  played,  for  each  enemy 
vehicle  which  is  to  be  hit,  there  must  be  entered  probabilities  of 
kill.  The  names  of  all  affected  units  must  be  entered. 
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IZ.X  obsouratioB  rila 

This  fils  dsfinss  ehsngss  in  ths  staosphsric  conditions  during 
ths  battle.  Thsss  changes  affect  all  conbatants  across  the 
battlefield,  dnoke  in  the  model  starts  at  a  certain  time,  and  has 
a  finite  duration.  Both  of  these  parameters  are  set  by  the  user. 
Any  number  of  smoke  events  can  be  played  in  the  model,  but  the  more 
smokes  which  are  played  the  slower  the  run  time  will  be  since  all 
probabilities  of  acquisition  and  engagements  are  reassessed  when 
the  atmosphere  changes.  The  file  has  the  name  smkfile.  If  no 
smoke  is  desired  in  the  battle,  this  file  can  be  ignored,  and 
should  not  be  left  in  the  present  working  directory.  The  figure 
below  shows  the  format  of  the  file.  The  first  two  entries  on  each 
line  are  the  starting  time  for  the  smoke  and  the  duration  of  the 
smoke.  The  next  three  entries  are  the  attenuations  of  transmission 
for  optical,  thermal,  and  radar  sensors  respectively. 


*****  CooBtent  Line(s) 

*•  start 

duration  optic 

therm 

radar 

300. 

400.  8.0 

1.0 

0.0  * 

smoke 

lasts  from  300  to  700  sec. 

100. 

50.  2.1 

.74 

0.3  * 

smoke 

2  lasts  from  100  to  150  sec. 

Pigur*  14  Battlefiald  Obscuration  Pile 
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ZZ.J  Sngag«a«nt  Control  Filo 

With  th«  inclusion  of  fratricide  into  tha  nodal,  a  nav  file  is 
used  to  dascriba  vhich  units  can  angaga  ona  another.  This  file 
aliainatas  tha  need  for  tha  simulation  to  calculate  all  of  tha 
angagamant  interactions  that  would  taka  place  between  two  units 
which  would  never  realistically  angaga  ona  another. 

Thera  is  only  ona  file,  angfila,  which  describes  tha  actions 
of  both  RED  and  BZCB  units.  If  fratricide  is  not  desired,  this 
file  can  be  ignored,  and  tha  modal  will  revert  to  normal  play  with 
units  engaging  only  enemy  units;  no  friendly  losses  will  occur. 
This  file  is  complicated  and  the  user  should  be  sure  of  his/her 
changes. 

Engagement  is  governed  in  the  model  by  three  parameters.  The 
first  parameter  is  a  yes  or  no  switch  which  determines  if  the 
engaging  unit  engages  units  of  each  of  the  other  types.  Given  that 
an  observer  acquires  a  target,  a  check  is  than  made  to  determine  if 
he  is  able  to  identify  the  target  through  his  sensor  as  either 
friendly  or  enemy.  Zf  he  is  able  to  identify  the  target  as 
friendly,  ha  will  break  off  the  engagement.  Zf  he  identifies  as  an 
enemy,  he  will  engage  tha  target  as  normal.  Zf  he  is  not  able  to 
identify  the  target  one  way  or  the  other,  he  must  make  some 
decision  whether  he  should  engage  this  **grey*'  target.  This 
decision  is  characterised  in  the  model  by  the  last  two  parameters, 
the  probability  of  engagement,  and  a  time  delay  associated  with  the 
decision. 


Engaging  Unit's  Name 
--  Target  names,  Is-It-A-Tgt, 

P(engage) 

T (engage) 

Engages  1  x 

x.xx 

XX.  X 

Engages  2  x 

x«xx 

XX. X 

'END' 

Figur*  15  Engagement  Control  File  -  structure 


The  engagement  file  contains  a  subunit  for  each  unit  type  in 
the  battle.  The  general  structure  of  a  single  subunit  is  shown  in 
the  figure  above.  The  first  entry  in  each  subunit  is  the  engaging 
*  unit's  name.  After  the  next  comment  line,  there  is  a  single  line 
entry  for  all  units  which  the  engaging  unit  My  consider  as  a 
target.  On  each  line  are  the  engaged  unit's  name  and  the  three 
parameters  mentioned  previously.  For  the  yes  or  no  decision,  enter 
a  1  or  0  for  yes  and  no,  respectively.  For  the  probability  of 
engaging  given  that  the  engaging  unit  is  unable  to  identify,  and 
the  time  delay  for  the  decision  eater  the  appropriate  numbers, 
instead  of  listing  all  of  the  units  in  the  battle,  and  entering  a 
0  for  the  ones  not  to  be  engaged,  the  user  can  enter  only  those 
wanted,  and  end  the  subunit  by  entering  END  as  the  unit  name. 
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A  sample  engagement  Tile  is  shown  below.  Vhe  first  subunit  is 
for  unit  type  BUNITl .  BUNITl  will  engage  both  BUMIT2  and  RUNITl . 
However,  when  he  cannot  identify  a  target  which  he  has  detected,  he 
will  engage  BUNIT2  only  40%  of  the  time,  but  he  will  engage  RUNITl 
100%  of  the  time.  This  may  be  because  RUNITl  may  be  further  away 
or  in  an  area  where  BUNITl  knows  there  are  no  friendly  units,  and 
BUNIT2  may  be  in  an  area  where  there  is  a  good  chance  that  friendly 
vehicles  may  be  located.  BUNIT2  has  the  location  of  BUNITl  and 
will  only  engage  RUNITl.  RUNITl  will  engage  both  BLUE  luiits,  and 
he  will  always  engage  on  detection  since  his  probabilities  of 
engaging  are  1.0. 


********  Engagement 
'BUNITl' 

Table  ••*•* 

*  * 

—  Target  name, 
'BUNIT2' 

is-it-a-tgt. 

p (engage) , 

t  (ei.gage) 

1 

0.4 

5. 

'RUNITl' 

'END' 

*  *  ♦  * 

'BUNIT2' 

1 

1.0 

0. 

—  Target  name. 

is-it-a-tgt. 

p (engage) , 

t (engage) 

'RUNITl' 

'END' 

*  e  w 

'RUNITl' 

1 

1.0 

5. 

—  Target  name, 
'BUNITl' 

is-it-a-tgt. 

p (engage) , 

t (engage) 

1 

1.0 

0. 

'BUNIT2' 

'END' 

1 

1.0 

0. 

Figure  16  Engagement  Control  File  -  sample 
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II. K  Combat  Identification  File  1 

Only  if  the  engagement  file  exists  can  the  user  play  combat 
identification.  The  first  type  of  combat  identification  is  a 
system  which  has  all  friendly  vehicles  constantly  emitting  a  CID 
signal  (CIOl)  which  friendly  units,  and  sometimes  enen^  units,  can 
detect .  When  a  unit  with  this  type  of  CID  is  detected  by  a 
friendly  observer,  there  is  a  probability  associated  with  the  CID 
that  the  observer  will  then  know  that  the  CID  host  is  friendly  and 
if  this  probability  is  met,  the  observer  will  disengage  the  target. 
The  CID  signal  being  emitted  can  also  aid  others  in  detecting  the 
host  units.  This  aspect  of  the  CID  is  modelled  as  a  probability  of 
detection  in  a  given  time  period.  If  the  time  period  were  30 
seconds,  for  exaiqple,  a  random  draw  is  done  every  30  seconds  to 
determine  if  any  of  the  searching  units  will  detect  the  host 
because  of  its  signal. 

The  information  to  characterize  these  events  is  entered  in  the 
input  file  "cidfill".  If  this  file  is  not  included  in  the  current 
working  directory  this  part  of  the  code  will  be  ignored.  The  file 
contains  a  siibunit  for  each  different  unit  type  in  the  battle  which 
has  a  CIDl  on  board;  the  figure  below  shows  a  single  subunit . 


****  Comment  Line(s) 

♦  *  ♦  ★ 

— CID  Host  Name,  Time  for 

Detection  check 

'BUNITl' 

30. 

—  Probability  of 
'BUNIT2'  x.xx 

these 

observers  CIDing  host  vehicle 

x.xx 

x.xx  x.xx  x.xx  x.xx 

x.xx  ... 

'END' 

—  Probability  of 

these 

observers  detecting  host 

vehicle' s  CID  signal 

'BUNIT2'  x.xx 

x.xx 

x.xx  x.xx  x.xx  x.xx 

x.xx  ... 

'RUNITl'  x.xx 
'END' 

x.xx 

x.xx  x.xx  x.xx  x.xx 

x.xx  ... 

Figure  17  Combat  Identification  File  1  -  structure 


The  first  entry  is  the  name  of  the  CIDl  host  unit.  On  the 
same  line,  the  user  enters  the  time  between  CID  detection  at  tenets . 

.  The  information  in  the  first  section  is  the  probability  of  the 
friendly  units  being  able  to  CID  the  host  unit  upon  detection. 
Each  line  will  contain  the  name  of  the  observer  unit,  and  the 
probabilities  that  this  observer  will  CIDl  as  a  function  of  range. 
In  the  next  section  enter  the  probabilities  of  friendly  and  enemy 
units  detecting  this  CIDl  host  because  of  its  CID  signal.  These 
probabilities  are  based  on  the  time  specified  previously.  The  user 
enters  the  name  of  the  observer  unit,  and  the  probabilities  of 
detection  as  a  function  of  range.  Both  sections  are  ended  by 
entering  an  'END'  in  place  of  the  unit  name. 
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***  Ranges:  500,  1000,  1500,  ... 

— CID  Host  Name,  Time  for  Detection  check 
'BUNITl'  30. 

—  Probability  of  these  observers  CIDing  host  vehicle 

'BUNIT2'  1.00  0.98  0.90  0.80  0.65  0.40  0.20  0.00 

'END' 


—  Probability  of  these 
'BUNIT2'  0.50  0.30 

'RUNITl'  0.30  0.15 

'END' 

— CID  Host  Name,  Time  for 
'BUNIT2'  30. 

—  Probability  of  these 
'BUNITl'  1.00  0.98 

'END' 

—  Probability  of  these 
'BUNITl'  0.50  0.30 

'RUNITl'  0.30  0.15 

'END' 


observers  detecting  host  vehicle' s  CID 
0.20  0.10  0.05  0.01  0.00  0.00 

0.07  0.03  0.01  0.005  0.00  0.00 

Detection  check 

observers  CIDing  host  vehicle 
0.90  0.80  0.65  0.40  0.20  0.00 

observers  detecting  host  vehicle's  CID 
0.20  0.10  0.05  0.01  0.00  0.00 

0.07  0.03  0.01  0.005  0.00  0.00 


signal 


signal 


Figure  18  Combat  Identification  File  1  -  san^le 


The  figure  above  shows  an  exas^le  of  a  CIDl  file.  From  the 
saoqple  engagement  file,  there  are  two  BLUE  iinit  types,  BUNITl  and 
BUNIT2,  and  1  RED  unit  type,  RUNITl.  The  first  subunit  in  the 
saoqple  CIDl  file  is  for  BUNITl  as  a  CIDl  host.  The  first  section 
shows  that  BUNIT2  has  a  0.50  probability  of  CIDing  BUNITl  at  500  m. 
and  that  probability  drops  to  0.20  at  3500  m.  The  next  section 
describes  BUNIT2  and  RUNITl 's  probabilities  of  detecting  BUNITl' s 
CIDl  signal  every  30  seconds.  So  if  RUNITl  were  2000  m.  away  from 
BUNITl,  RUNITl  would  have  a  3%  chance  of  detecting  BUNITl  every  30 
seconds.  If  an  observer  from  BUNIT2  detects  BUNITl 's  CIDl  signal, 
he  automatically  CIDs  BUNITl  as  friendly. 

The  second  siibunit  in  the  figure  shows  the  probabilities  when 
BUNIT2  has  a  CIDl  type  system  on  board.  Again  the  probabilities 
are  given  for  correct  CID  and  for  detection  of  the  CID  signal. 
There  is  no  subunit  for  RUNITl  because  RUNITl  does  not  have  a  CIDl 
on  board  in  this  battle. 
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II. L  Combat  Identification  File  2 


The  second  type  of  combat  identification  device  which  can  be 
played  is  a  query-response  type  system.  This  type  of  CID  is  used 
after  an  observer  detects  a  target  and  decides  to  fire  at  the 
target.  Just  prior  to  firing  at  the  target,  the  firer  q[ueries  the 
target,  ^md  tries  to  elicit  a  response  from  the  target.  If  the 
target  receives  the  signal  and  returns  a  response,  the  firer  will 
discontinue  the  firing  sequence,  disengage  the  target,  and  begin 
looking  for  new  targets. 

Associated  with  this  query  and  response  are  four  probabilities 
aind  a  time  delay.  The  diagram  below  shows  the  meaning  of  each  of 
these  inputs.  PI  is  the  probability  that  when  the  host  queries  a 
target,  the  signal  will  reach  the  target.  P3  is  the  probability 
that  the  target's  response  will  get  back  to  the  host  vehicle.  P2 
and  P4  are  the  probabilities  that  the  target  and  then  the  host 
vehicle  will  correctly  interpret  the  query  and  response, 
respectively.  The  time  delay  is  singly  the  time  from  the  initial 
query  to  the  observer 
interpreting  the 
response .  Nhat  the 
diagram  does  not  show  is 
that  when  the  target 
sends  out  its  response, 
there  may  be  some  chance 
that  the  response  will 
be  detected  by  enemy 
units,  which  may  then 
engage  that  target. 

The  input  file  for  this  type  of  CID  is  named  "cidfil2".  This 
file  is  divided  into  subunits  for  each  unit  type  in  the  battle. 
The  structure  of  the  subunit  is  shown  in  the  next  figure.  For  the 
CIDl  stibunit  the  inputs  described  what  others  could  do  to  the  host 
vehicle.  For  CID2  the  user  inputs  the  probabilities  which  describe 
what  the  host  vehicle  can  do  to  others. 

The  next  figure  shows  the  structure  of  the  CID2  subunit . 
After  the  name  of  the  host  or  querying  unit,  the  first  input  is  the 
nximber  of  times  this  unit  will  query  a  target  before  engaging  it. 
If  the  firer  receives  a  positive  response  from  any  query  he  will 
disengage  the  target,  and  not  query  again.  If  this  unit  has  no  CID 
then  the  input  is  0.  On  the  next  two  lines  enter  the  time  delay 
associated  with  the  CID2,  and  PI  as  described  above,  as  a  function 
of  range  between  firer  and  target.  Next  there  is  a  subsection  for 
each  unit  type  to  be  queried  by  the  CID.  Within  each  subsection 
the  user  enters  the  target  unit's  name,  and  P2  through  P4.  The 
section  must  be  ended  with  an  END'  as  the  target  name.  The  last 
section  in  the  8id»unit  defines  the  chance  for  the  host  vehicle  to 


figure  19  Combat  Identification  Type  2 
Methodology 
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-  CID  Host  Unit 

Host  Name 

X 

***  Number  of  CID  Attempts 

X  .  XX  X  .XX  X  . 

XX  x . 

XX 

. 

**•  CID  Time  Delay 

X.XX  X.XX  X. 

XX  X. 

XX 

***  PI 

-  Probability 

Target 1  Name 

of  CID2  Against  These 

Targets 

X.XX  X.XX 

X.XX 

X.XX 

X.XX  ... 

***  P2 

X.XX  X.XX 

X.XX 

X.XX 

X.XX  ... 

***  P3 

X.XX  X.XX 

Target 2  Name 

X.XX 

X  ,  XX 

X.XX  ... 

***  P4 

X.XX  X.XX 

X.XX 

X.XX 

X.XX  ... 

*•*  P2 

X.XX  X.XX 

X.XX 

X  .  XX 

X.XX  ... 

P3 

X.XX  X.XX 

'END' 

X.XX 

X.XX 

X.XX  ... 

***  p4 

-  Probability 

of  Detecting 

These  Targets'  Responses 

Target  1  x. 

'END' 

XX  X  . 

XX  X . 

XX  X.XX 

X.XX  ...  ***  P (detect) 

Figure  20  Combat  Identification  File  2  -  structure 


detect  a  target  when  it  responds  to  a  CID2  query.  For  each 
appropriate  target  unit  type,  enter  the  target  name  and  the 
probability  as  a  function  of  range  that  the  host  unit  will  detect 
it. 

The  next  figure  shows  a  saxq>le  of  a  CI02  file.  BUNITl  has  a 
CID2  type  device  on  board  and  will  query  a  target  1  time  before 
engaging  it.  The  time  delay  associated  with  its  CIO  varies  from  1 
second  at  500  m.  to  5  seconds  at  3500  m.,  and  its  probabilities  of 
CID  are  very  high.  BUNITl  is  only  able  to  CID  BUNIT2  since  there 
is  no  entry  for  RUNITl.  KJNITl  is  also  able  to  detect  BUNIT2  when 
it  responds  to  a  query.  If  a  firer  from  BUNITl  queries  a  \init  from 
BUNIT2,  other  observers  from  BUNITl  have  a  0.1  probability  of 
detecting  that  response  at  2000  m. 

The  same  is  true  when  BUNIT2  is  the  host  platform.  Its  time 
delay  also  ranges  from  1  to  5  seconds,  but  it  will  try  to  query  a 
target  twice  before  engaging.  Its  probabilities  of  CID  are  a  bit 
lower  than  BUNITl' s. 

RUNIT  does  not  have  a  CID  on  board,  but  is  able  to  detect  both 
BUNITl  and  BUNIT2'8  CID  responses.  These  probabilities  of 
detection  are  entered  in  the  last  section  in  the  figure.  For 
exasple,  when  BUNITl  queries  BUNIT2,  RUNITI  has  a  probability  of 
detecting  that  response  of  .2  at  500  m. 
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***  Comment  Line<s)  *** 

BUN IT 1 

1 

***  Number  of  CID  Attempts 

1.0  1.2  1.5  2.0  2.5  3.5  5.0 

***  CID  Time  Delay 

1.0  1.0  1.0  1.0  1.0  1.0  0.85 

***  PI 

-  Probability  of  CID2  Against  These 

Targets 

BUNIT2 

1.0  1.0  1.0  1.0  1.0  1.0  1.0 

**♦  P2 

1.0  1.0  1.0  1.0  1.0  1.0  0.85 

***  P3 

1.0  1.0  1.0  1.0  1.0  1.0  1.0 

**♦  P4 

'END' 

-  Probability  of  Detecting  These  Targets'  Responses 

BUNIT2  0.2  0.2  0.2  0.1  0.1  0.0  0.1 

3 

'END' 

***  Comment  Line(s>  *•* 

BUNIT2 

2 

***  Number  of  CID  Attempts 

1.0  1.0  1.0  1.0  1.0  3.0  5.0 

***  CID  Time  Delay 

0.5  0.5  0.3  0.3  0.2  0.1  0.00 

***  PI 

-  Probability  of  CID2  Against  These  Targets 

BUNITl 

1.0  1.0  1.0  1.0  1.0  1.0  1.0 

***  P2 

1.0  1.0  1.0  1.0  1.0  1.0  0.85 

*»*  P3 

1.0  1.0  1.0  1.0  1.0  1.0  1.0 

***  P4 

'END' 

-  Probability  of  Detecting  These  Targets'  Responses 

'END' 

***  Comment  Line{s>  *** 

RUNITl 

0 

***  Number  of  CID  Attempts 

7*0.0 

***  CID  Time  Delay 

7*0.0 

**•  PI 

-  Probability  of  CID2  Against  These 

Targets 

'END' 

-  Probability  of  Detecting  These  Targets'  Responses 

BUNITl  1.0  1.0  1.0  1.0  1.0  1.0  1.0 

»**  P (detect) 

BUNIT2  0.2  0.2  0.2  0.1  0.0  0.0  0.0 

***  P (detect) 

'END' 

Figure  21  Combat  Identification  File  2  -  sample 


Ill  RELEASE  AUTHORITY 


Tho  Groundtrars  Model  is  the  property  of  the  Federal 
Government.  The  model  may  be  released  to  any  government  agency 
which  has  a  use  for  it .  However,  release  to  a  government  agency 
does  not  give  authority  for  that  agency  to  release  the  model  to 
other  agencies  or  contractors. 

Contractors  are  permitted  use  of  the  model  if  there  exists  a 
contract  with  the  government  which  requires  its  use.  Contractors 
are  required  to  have  their  government  point  of  contact  provide  this 
office  with  a  letter  of  request.  Upon  receipt  of  this  request, 
AMSAA  will  provide  the  contractor  with  a  Memorandijm  of  Agreement 
for  the  use  and  modification  of  the  model.  Upon  execution  of  this 
agreement,  AMSAA  will  provide  the  model  to  the  government  POC,  who 
in  turn  provides  it  to  the  contractor. 

Any  modifications  which  are  made  to  the  model  should  be 
provided  to  this  office.  Any  errors  in  the  model  should  be 
addressed  to  one  of  the  points  of  contact  in  the  next  section. 
Requests  for  the  model  should  be  sent  to: 

Director 

US  Army  Materiel  Systems  Analysis  Activity 
ATTN:  AMXSY-GC  (L.  Harrington) 

Aberdeen  Proving  Ground,  MD  21005-5071 
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17  POIMTS  or  CONTACT 


Th«  following  list  providos  points  or  plscss  of  contsct  for 
qusstions  psrtsining  to  ths  Groundwsrs  Modsl  and  rsguirsd  input 
data. 


ftrti  point fs)  of  contact 

GROUMDlfARS  Modal  Mr.  Gary  Coastock  (D8M  298-2079) 

Mr.  Barry  Burns  (DBM  298-7289) 

Ms.  Lilly  Barrington  (D8N  298-3239) 
Mr.  Michaal  Bcbaidt  (DBM  298-7290) 
Coabinad  Aras  and  Barriar  Warfara 
Analysis  Branch  (CABBAB) ,  AMZBY-GC 
Ground  warfara  Division^  AM8AA 


Vulnarability  Data 


Vulnarability/Lathality  Div  (VLD) , 
BRL 


Tarrain  Data  Mr.  Danny  Chaapion  (DBM  258-5891), 

TKAC,  Whita  Bands  Missila  Ranga, 
MM 


firing  Cyola  Tiaas 
Dalivary  Accuracy 


Targat  Acquisition 


Mr.  crassa  Bravar  (DBM  298-3374), 
Araorad  Warfara  Analysis  Branch 
Mr.  Edward  Walkar  (DBM  298-5356), 
Infantry  Warfara  Analysis  Branch 

Mr.  Richard  Maian  (DBM  298-2274) 
Mr.  Jaff  Matthaws  (DBM  298-7287) 
CABWAB,  6WD,  AMBAA 


(CcMUiarcial  phona  prafiz  for  AMBAA  and  ARL  is 
(410)-278-XXXZ) 


COMBAT 
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DISTRIBUTION  LIST 


Copies  Organization 

3  Director 

US  Amy  Armanent  ROSE  Center 
ATTN:  SMCAR-FSS-E  (J.  Brooks) 
SNCAR-FSr-B  (B.Gullifer) 
SMCAR-FS-A(l)  (R.  Collett) 
Ficatinny  Arsenal, NJ  07806-5000 


2  CosBsander 

US  Amy  Survivability 
Manageaent  Office 
ATTN:  SLCSM-SE  (B.  King) 
SLCSM-D  (F.  Kanion) 
2800  Powder  Mill  Road 
Adelphi,  MD  20783-1145 


7  CoDsnander 

Defense  Technical  Information 
Center 

ATTN:  DTIC-FDAC 
Cameron  Station,  Bldg  5 
Alexandria,  VA  22304-6145 


1  Director 

US  Army  Vulnerability  Assessment 
Office 

ATTN:  SLCVA  (D.  Mathews) 
ffhite  Sands  Missile  Range,  NM 
88002-5513 


5  Commander 

US  Ars^  Missile  Comoumd 
ATTN:  AMSMZ-OR-SA  <N.  Powell) 
(J.  Smith) 

AMSMI-RD-SM  (H.  Barber) 
AMSMI-RD-SS 
AMSMZ-SW  (C.  George) 
Redstone  Arsenal, AL  35898-5060 


1  Commander 

US  Azsv  Amor  Center 
ATTN:  ATZK-CDC  (X..  Vowels) 
Fort  Knox,  KT  40121-5212 


2  Commander 

US  Army  Tank  Autosotive  Command 
ATTN:  ANSTA-VSA  (M.  Kerr) 
ANSTA-RSC  (B.  Bowdoin) 

Narren,  NX  48397-5000 


Copies  Organization 

1  Commander 

US  Amy  Communications-Electronics 
Cosenand  at  Ft.  Monmouth 
ATTN:  JUfSEL-RD-EN-C  (J.  Hardy) 

Fort  Monmouth,  NJ  07703-5000 


1  Commander 

US  Amy  CECOM  Center  for  Night 
Vision  and  Electro-Optics 
ATTN:  AMSEL-RD-NV-GSD  (J.  England) 
Fort  Belvior,  VA  22060-5677 


1  Commander 

US  Army  Natick  Research  Development 
and  Engineering  Center 
ATTN:  STRNC-AC  (J.  O'Keefe) 

Natick,  HR  01760-5000 


3  Program  Executive  Office 

Armored  Systems  Modernization 
ATTN:  SFAE-ASM-SS-P  (D.  Bjoraker) 

\,l4.  Jokiibaitis) 
m»xxexi,  Ml  48397-5000 


1  BQDA 

ATTN:  SAUS-OR  (LtC.  Hardy) 
Pentagon,  Room  1B643 
Washington,  DC  20310-0102 


2  B(^A 

ATTN:  SARD-DO  (Col.  Bigelman) 
(Maj.  Decker) 

Washington,  DC  20310-0102 


1  Analysis  and  Simulation,  Inc. 
ATTN:  P.  Patti 

172  Holtz  Road,  One  American  Park 
Buffalo,  NY  1422'% 


1  Dyneties,  Xnc. 

P.O.  Drawer  B 
ATTN:  T.  Gil 

Huntsville,  AL  35814-5050 
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Copiss  Orgsnisstion 


copiss  Organisation 


1  0«ii«ral  Drnasics  Land  STStana, 
axZMi  J.  Kayas 
P.O.  Box  307d 
Warran,  MX  48090-2074 
Nall  Sona  434-21-19 


1  Barculas  Dafanaa  Blactronica 
Syatasa,  Xne. 
aXXM:  J.  Harriaon 
P.O.  Box  4448 
Claarwatar,  PL  34418 


Inc.l  Noaiura  Bntarprlaaa,  Znc. 
axXMi  J.  Manna 
2832  Piftb  Straat 
Bock  Zaland,  XL  41201 


1  suavxac  Satallita  Offica 
axiHt  M.  McOinnia 
Sta.  1410 

1300  Mortb  Saaantaantli  Straat 
Soaalyn,  va  22209 


1  Kasan  Sclancaa  Corporation 
axXNt  L.  Owan 
P.O.  Box  7443 

Colorado  Springa,  CO  80933-7443 


Absrdssn  Proving  Ground 

1  Dlractor 

any  Roa<  ■arch  lAboratory 
aXXN:  SLCBR-SB  (P.  Bunn) 

40  Oiraetor 

US  amy  Matarial  Syatana  Snalyala  activity 
axTM:  aNZST-0  (John  Krasar) 
aNZSr-oa  (Jaaca  Brawar) 

(Wilbart  Brooka) 

(Mika  Dawita) 

(Diardra  Minor) 

(Son  Ruth) 

(Barry  Siagal) 

(Joa  Valantina) 

(Bill  Taakal) 
aNZST-OC  (Barry  Buma) 

(Bd  Chriataan) 

(Gary  Coaatoek) 

(Lilly  Harrington) 

(Robart  Kraiaal) 

(Thonaa  B.  Nalonay) 
(Richard  Maaan) 

(Mika  Ray) 

(Nika  Schnidt) 

(Alax  Nong) 

14  axtra 

RMZST-OZ  (Jaff  Corlay) 

(Harvay  Xaa) 

(Ran  Hilton) 

(Rich  Scungio) 

RNZST-OS  (Ban  King) 

HMZST-C  (Rich  Sandnayar) 

AMZSY-PA  (RPC,  3eya) 
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AMXSY-GC 


GIST 


In-House  Analysis 

SUBJECT:  Technical  Report  530,  Groundwars  Version  5.0  -  User's  Guide 
PRINCIPAL  FINDINGS:  NA 

MAIN  ASSUMPTIONS:  NA 

PRINCIPAL  LIMITATIONS:  NA 


SCOPE  OF  THE  EFFORT:  Groundwars  Combat  Simulation.  Ground  to 

ground  combat  simulation  of  a  two  sided  battle  between  heterogeneous 
forces . 


OBJECTIVE:  To  document  the  input  requirements  of  the  model  and  to  inform  the 
useir  of  the  requirements  and  capabilities  of  the  model. 


BASIC  APPROACH:  The  simulation  is  based  on  Monte  Carlo  probability  theory  for 
simulating  randomness.  Combat  simulation  standard  approaches  are  used  for 
simulating  combat. 


REASON  FOR  PERFORMING  THE  EFFORT;  To  document  the  input  requirements  of  the 
model  for  user  execution  at  other  government  sights  and  at  appropriate 
contractors . 


IMPACT  OF  THE  EFFORT:  NA 


SPONSOR:  U.S.  Army  Materiel  Systems  Analysis  Activity 


PRINCIPAL  INVESTIGATOR:  Michael  C.  Schmidt 


COMMENTS  AND  QUESTIONS: 

AMXSY-GC  Attn{M.  Schmidt) 

Aberdeen  Proving  Ground,  MD  21005-5071 
DSN  298-4413,  Comm.  1-410-278-4413 


DTIC/DLSIE  ACCESSION  NUMBER:  Report  sent  to  DTIC  (number  not 

available) .  Report  available  by  contacting  AMSAA' s  Reports 
Processing  Center,  DSN  298-4661. 


WHO  COULD  BENEFIT  FROM  THIS  REPORT:  Numerous  outside  government  agencies  use 
the  Groundwars  model  to  conduct  weapon  systems  analyses.  Also  defense 
contractors  which  use  the  model  need  this  report  to  format  input  data. 


